I have little experience with Windows 8 and our organization does not yet support it but some end users have it.

Users running Windows 8.1 and IE 11 have presumably created a live tile referencing our secure application.  We are seeing user requests to <server>/browserconfig.xml with no authentication cookies while the user is currently authenticated in IE.  Windows appears to not send existing authentication session cookies in the request but is processing response cookies.  This is causing the user to become unauthenticated.  One user claims to have removed the tile from their desktop but we are still seeing requests to browserconfig.xml from that user.  When that user ran IE developer tools and logged network traffic, we see the transition from authenticated to unauthenticated once our authentication cookie value changed.  IE did not log the request that changed the cookie.  IE did not log the request to browserconfig.xml at all, presumably because it was in a different thread.  Our server did log this additional request.  The request to browserconfig.xml consistently occurs between the change from authenticated to unauthenticated.

Questions:

1.  Is the request to browserconfig.xml expected to include cookies (both session and not) in the request?  If not, why does Windows appear to process response cookies?

2.  The user claimed to have removed the tile.  If this is true, is there a difference between hiding and deleting tiles?  We are still seeing requests to browserconfig after the user claimed to have removed it.  Unfortunately, I cannot confirm the user claim.

• Edited by James.O Thursday, July 02, 2015 7:20 PM

Thank you for your reply Roger, but that does not address my questions.  My application does not use or actively support live tiles.  Something on the end user's machine is causing the OS to send periodic requests to browserconfig.xml even though the user stated a previously created tile was deleted.  When it happens, the user is no longer authenticated to our application, due to a change in the authentication cookie.  Presumably this is happening because the browserconfig request does not include the original authentication cookie and our application is responding with a login page and a new session cookie.  This new cookie is then sent with subsequent requests by the user.  If the OS is not sending outgoing cookies in a background request, it should also not process any incoming cookies.